Method and apparatus for providing dynamic warnings for navigations

ABSTRACT

A navigation application that provides a dynamic set of warnings based on a set of collected and calculated data. The navigation application collects a series of data and identifies a set of critical points along the route. The navigation application analyzes the collected data to determine whether to provide a navigation warning to the user. The navigation application uses the collected data to determine whether a navigation instruction for the critical point should be modified to account for different driving conditions. Finally, the navigation application of some embodiments determines a timing for when a navigation instruction should be provided to the user, ensuring that the instruction is presented to the user with sufficient time to safely adjust their behavior.

CROSS-REFERENCE TO RELATED APPLICATION

This is a continuation of U.S. patent application Ser. No. 14/503,303filed Sep. 30, 2014, which is incorporated by reference herein in itsentirety.

BACKGROUND

Mapping and navigation applications allow users to browse maps and getnavigation instructions for different routes. Some navigationapplications provide warnings for users of the application whilenavigating a route. Despite their popularity, the mapping and navigationapplications and the warnings that they provide have shortcomings thatcause inconvenience to the users.

BRIEF SUMMARY

The invention of some embodiments provides a navigation application thatpresents a dynamic set of warnings. The navigation application collectsa series of data and identifies a set of critical points along theroute. The critical points of some embodiments are dangerous areas ofthe route based on the collected data. The navigation application ofsome embodiments analyzes the collected data to determine whether toprovide a navigation warning to the user. For example, in someembodiments, the navigation application analyzes the collected data todetermine a safe traveling speed for a particular critical point anddetermines whether to provide a navigation warning to the user based onthe user's current traveling speed.

In some embodiments, the navigation application uses the collected datato determine whether a navigation instruction for the critical pointshould be modified to account for different driving conditions. Forexample, in some embodiments the navigation application determines thata navigation instruction should be modified when the road conditions areparticularly poor. The navigation application of some embodiments alsodetermines a timing for when a navigation instruction should be providedto the user based on the collected data to ensure that the instructionis presented to the user with sufficient time to safely adjust theirbehavior.

The preceding Summary is intended to serve as a brief introduction tosome embodiments of the invention. It is not meant to be an introductionor overview of all inventive subject matter disclosed in this document.The Detailed Description that follows and the Drawings that are referredto in the Detailed Description will further describe the embodimentsdescribed in the Summary as well as other embodiments. Accordingly, tounderstand all the embodiments described by this document, a full reviewof the Summary, Detailed Description and the Drawings is needed.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth in the appendedclaims. However, for purpose of explanation, several embodiments of theinvention are set forth in the following figures.

FIG. 1 conceptually illustrates a process for providing dynamicnavigation warnings.

FIG. 2 illustrates an example of a scenario in which a dynamicnavigation warning is provided to a user.

FIG. 3 conceptually illustrates an example of a dynamic warning system.

FIG. 4 conceptually illustrates a process for generating dynamicnavigation warnings.

FIG. 5 illustrates different scenarios in which a navigation applicationdetermines whether to provide a navigation warning.

FIG. 6 illustrates different scenarios in which a navigation applicationmodifies different aspects of a navigation warning.

FIG. 7 illustrates an example of modifying the timing for a navigationwarning.

FIG. 8 illustrates an example of an architecture of a mobile computingdevice.

FIG. 9 illustrates a map service operating environment.

DETAILED DESCRIPTION

In the following detailed description of the invention, numerousdetails, examples, and embodiments of the invention are set forth anddescribed. However, it will be clear and apparent to one skilled in theart that the invention may be practiced without some of the specificdetails and examples discussed.

In order to provide better navigation instructions for a user of anavigation application, the navigation application of some embodimentsprovides dynamic navigation instructions. The dynamic navigationinstructions take various factors into account to enable a user tosafely maneuver through potentially dangerous areas without overwhelmingthe user with unnecessary navigation instructions.

The navigation application of some embodiments provides a dynamic set ofwarnings. The navigation application collects a series of data andidentifies a set of critical points along the route. The critical pointsof some embodiments are dangerous areas of the route based on thecollected data. The navigation application of some embodiments analyzesthe collected data to determine whether to provide a navigation warningto the user. In some embodiments, the navigation application uses thecollected data to determine whether a navigation instruction for thecritical point should be modified to account for different drivingconditions. The navigation application of some embodiments determines atiming for when a navigation instruction should be provided to the user,ensuring that the instruction is presented to the user with sufficienttime to safely adjust their behavior.

FIG. 1 conceptually illustrates a process for providing dynamicnavigation instructions along a route. In some embodiments, the process100 of FIG. 1 is performed by a dynamic warning system as describedbelow in FIG. 3. The process 100 may be performed at specifiedintervals, continuously, or may be performed each time new navigationinstructions are received by the navigation application.

The process 100 collects (at 105) various information, such as route andhazard data, external conditions (i.e., as weather, road conditions,etc.) as well as internal vehicle conditions (i.e., speed, tirecondition, brake condition, etc.). The process 100 then uses thereceived information to identify (at 110) a set of critical points alongthe route. The critical points may include hazardous curves, roadhazards (e.g., potholes, construction, etc.), or other points along theroute that may require additional attention. The critical points may beidentified based on road vector data, accident data, road hazard data,etc.

The process 100 then calculates (at 115) additional information in orderto generate the dynamic navigation warnings. The additional informationin some embodiments includes data that can be used in determining whattype of navigation warning to generate (e.g., safe stopping distance,visibility, etc.).

The process 100 determines (at 120) whether to present a navigationwarning based on the collected data and the calculated information. Whenthe process 100 determines that a navigation warning is necessary, theprocess 100 generates (at 125) a navigation warning for the criticalpoint based on the various collected and calculated information toprovide safe warnings for the user. Generating the warning in someembodiments includes determining whether to provide a warning at all,modifying a warning based on driving conditions, determining what typeof warning to provide, and determining when to provide the warning tothe user.

In some embodiments, the timing, instruction, and method of providing ofa navigation warning may all be modified based on the collected andcalculated information. For example, when a user is traveling in snowyand dark conditions, an audio warning may be provided earlier to cautionthe user to drive slower, than when the user is traveling in sunny anddry conditions.

When the process 100 determines (at 120) not to present a warning, theprocess 100 ends. Although generating a new navigation warning for acritical point was described, in some embodiments generating anavigation warning includes modifying existing warnings based on thecollected information.

The steps of process 100 may not always be performed in the same order.For example, although data collection is described in a single step(step 105 of FIG. 1), the data collection of some embodiments mayinstead take place at various different points during the process, ormay be continually updated as the process is performed. In someembodiments, different types of data is collected at different pointsduring the process (e.g., route data is collected to identify criticalpoints, while weather information may not be collected until thenavigation instructions are generated), or the same data may becollected and refreshed multiple times during the process.

Having described an example process, an example of providing a dynamicnavigation warning will now be described by reference to FIG. 2. FIG. 2illustrates an example of a scenario in which a dynamic navigationwarning is provided to a user of a navigation application. The firststage 201 illustrates a road 205 with a curve 220, a vehicle 210, and awarning sign 215.

In the first stage 201, the vehicle 210 is traveling along the road 205.The user is running a navigation application on a mobile device (e.g., asmartphone, GPS system, etc.) to get navigation instructions for aparticular route. The vehicle 210 is approaching the curve 220. Thenavigation application of some embodiments collects data, such asweather, vehicle, and road conditions, as well as route data to thenidentify the curve 220 (or the warning sign 215) as an upcoming criticalpoint. In this example, the speed of the vehicle is 55, which is a safetraveling speed based on the current conditions. The navigationapplication of some embodiments also calculates additional conditionfactors, such as a safe stopping distance, visibility, etc.

In the second stage 202, the vehicle 210 has progressed along the road205 and is closer to the curve 220. The second stage 202 further showsthat the user is presented with a dynamic navigation warning 225. Thenavigation warning 225 may be dynamic for a variety of reasons. In someembodiments, whether the navigation warning is presented at all isdynamic, based on various environmental and vehicle conditions. In someembodiments, the instruction, or the timing, or the method of presentingthe navigation warning is dynamic, changing based on the variousenvironmental or vehicle conditions. As examples, a warning may only bepresented in certain road conditions, or may be presented earlier whenit is snowing, or may be presented as an audio instruction when roadvisibility is low. In this example, the navigation application providesa warning 225 to reduce the user's speed to 45 mph for the upcomingcurve 220.

FIG. 3 illustrates an example of a dynamic warning system 300 thatgenerates dynamic warnings during navigation. The dynamic warning system300 of some embodiments runs as an application on a mobile device, suchas a GPS navigation device, a mobile phone, etc. Although the inventionis described as a part of a navigation application, some embodimentsprovide warnings outside of a navigation application. In someembodiments, the warnings are provided by a background application thatis able to provide navigation warnings to a user, even when the user isnot receiving navigation instructions.

The dynamic warning system 300 includes a data collector 305, a criticalpoint identifier 310, a calculation engine 315, and a warning generationmodule 320. The dynamic warning system 300 receives inputs from dataservice 335 and external sensors 340 and outputs the generated dynamicwarnings to the output module 345. In some embodiments, the output ispresented on a display screen of the device or as an audio instructionthrough speakers of the device.

In some embodiments, the dynamic warning system 300 periodicallyperforms automated processes that determine whether to provide and/ormodify navigation warnings for a route that is being navigated by auser. In some embodiments, the processes run periodically orcontinuously in the background of the application, only providing and/ormodifying navigation warnings when the dynamic warning system 300determines that the navigation warnings are necessary.

The data collector 305 of the dynamic warning system 300 collects datafrom various information sources. The various information sources may beinternal or external to the device on which the dynamic warning system300 is executed. In the example of this figure, data service 335 andexternal sensors 340 are external information sources accessed by thedata collector 305. The data service 335 includes multiple data servicesthat may be accessed by the data collector 305 through a network (suchas the Internet) or other communication channels. The data service 335provides multiple information services such as weather, traffic,navigation, etc. The data service 335 of some embodiments also includesdata that is obtained or collected from other users of the system. Theexternal sensors 340 of some embodiments include sensors of a vehicleused for navigating a route. Such external sensors 340 are used in someembodiments to detect environmental or vehicle conditions, such as roadconditions, brake conditions, etc.

In addition to the external information sources, the data collector 305also accesses various internal information sources, such as internalsensors 325 and route database 330. The internal sensors 325 of someembodiments include sensors located within the device, such as GPS, anaccelerometer, a gyroscope, WiFi sensors, etc. The internal sensors maybe used in the place of the external sensors 340, or to supplement thedata received from external sensors 340 to detect the environmentaland/or vehicle conditions.

The route database 330 stores information about the route. Theinformation stored in the route database 330 of some embodimentsincludes road hazard information, road vector data, accident statistics,etc. Although the route database is shown as a local database in thedynamic warning system, it should be understood that the route database330 may be an external database (e.g., located in the vehicle's computersystem, accessed through a data service 335, third party vendors, etc.).Although FIG. 3 illustrates an example with several different datasources, in some embodiments, data is not collected from all of theillustrated data sources and may be collected from additional datasources not shown in this figure.

The critical point identifier 310 receives data collected by the datacollector 305 and uses the data to identify upcoming critical pointsalong the route. The critical points may be determined based on roadvector data, accident data, road hazard data, etc. The critical pointsmay include hazardous curves, road hazards (e.g., potholes,construction, etc.), or other points along the route that may requireadditional attention. The critical point identifier 310 may alsoidentify a critical point based on visibility of a hazard or of signagenear a particular turn or road feature.

In some embodiments, the critical point identifier 310 uses thecalculation engine 315 to identify additional critical points. Forexample, in some embodiments, the critical point identifier 310 uses thecalculation engine 315 to calculate a risk factor for a particular curvebased on historic accident data or based on the angle of the curvecalculated based on road vector data.

The calculation engine 315 receives the critical points from thecritical point identifier 310, and uses data from the data collector 305to perform various calculations necessary to generate dynamic warningsfor the received critical points. The calculations are based on datafrom several of the information sources. For example, in someembodiments, the calculation engine 315 calculates a safe stoppingfactor based on tire and brake conditions of the vehicle received fromexternal sensors 340, weather information received from data service335, and road conditions received from route database 330. The safestopping factor can then be used in some embodiments to identify a safetraveling speed or an amount of time necessary to reach a safe travelingspeed for a particular critical point.

The warning generation module 320 uses the calculated and collectedinformation to generate dynamic warnings to present to the user. Thewarning generation module 320 determines (i) whether it is necessary toprovide a warning to the user, (ii) what type of warning to provide tothe user, (iii) how to modify the instruction for the user, and (iv)when to provide the warning to the user based on the collected andcalculated information. Some example operations of the warninggeneration module 320 will be described below by reference to FIGS. 4-7.

Once the warning generation module 320 has generated dynamic warningsfor the user, it supplies the navigation warning to the output module345. The output module 345 then presents the warning to the user (e.g.,on a display screen of the device or as an audio instruction throughspeakers of the device). The provision of dynamic navigation warningswas described generally above. Additional details for the differentparts of the process will be described in the sections below.

Section I describes the data collection process, which includesgathering data from the various data sources, identifying the criticalpoints, and calculating additional data based on the collected data andthe critical points. Section II, then describes the identification ofcritical points and the calculation of additional condition factors fordynamic navigation warnings. Next Section III describes the generationof dynamic warnings for navigation. Finally, Section IV describes anexample of an electronic device and system used to implement theprocesses of the invention.

I. Data Collection

In order to provide dynamic navigation instructions, the navigationapplication collects and calculates various sets of data. The varioussets of data are used at several different points of the process and arecollected from various sources through various methods. The navigationapplication collects several different types of information, includingroute information, vehicle information, and environmental information.

Route information may be collected from various sources (e.g., from alocal database or from a navigation service over the Internet, etc.).The route information of some embodiments includes road vectorinformation, accident data, road hazard data, traffic data, etc. Thecollected route information is used in some embodiments to identifycritical points along a route. For example, in some embodiments thenavigation application identifies road hazards (e.g., potholes,accidents, etc.) from a road hazard database as critical points. Thenavigation application of some embodiments also performs furthercalculations or analysis on the information to identify the criticalpoints. For example, the navigation application of some embodimentsidentifies a road feature (e.g., a sharp curve, steep incline, etc.), asa critical point based on a high accident rate at that particularlocation.

As with the route information, the vehicle information is collected frommultiple sources. The navigation application of some embodimentscollects the data directly from the vehicle, such as through vehiclesensors or an API that communicates with the vehicle computer. In someembodiments, the navigation application collects vehicle data from othersources, such as through user input (e.g., the user inputs the year,make, and model of the vehicle), or through sensors on a mobile deviceexecuting the navigation application (e.g., detecting the vehicle speedthrough a GPS module on the mobile device). The vehicle information ofsome embodiments includes car condition (e.g., tire age, brakeconditions, etc.), speed, acceleration profiles, etc. The collectedvehicle information is used to calculate different factors that areuseful in generating dynamic warnings. For example, in some embodiments,the car conditions and the weather are used to determine a brakingvariable that measures the ability of the vehicle to slow down or stopin the current conditions.

The environmental information describes the conditions of theenvironment around the vehicle. The environmental data of someembodiments includes weather conditions, ambient light detection, etc.The environmental data can be collected from various data sources of thenavigation application. For example, in some embodiments, wet roadconditions may be detected by sensors on the vehicle and also collectedfrom an external data source, such as an Internet weather service. Thedata is then used to further customize the navigation warnings for thecurrent road and weather conditions.

II. Critical Points and Condition Factors

The navigation application uses the various collected sets of data toidentify critical points along the route and to calculate additionalcondition factors that may affect the nature of a dynamic navigationwarning for a particular critical point. The navigation applicationidentifies critical points along a route that may require additionalattention. The critical points of some embodiments include hazardousroad features (e.g., sharp curves, steep inclines, etc.) and roadhazards (e.g., potholes, construction, etc.).

In some embodiments, rather than identifying a particular road featureas a critical point, the navigation application of some embodimentsidentifies a critical point based on visibility of a hazard or ofsignage near the particular road feature. For example, data collected bythe navigation application may reveal that signage for a particularsharp curve is not visible until the vehicle is within 150 m of thecurve. In some embodiments, rather than the curve itself, the navigationapplication would identify the visibility point of the signage (i.e.,150 m before the curve) as the critical point. Based on the visibilitypoint, the navigation application of some embodiments determines a safetraveling speed for approaching the curve that allows a driver to reactto the signage and reach a safe traveling speed for the curve itself.

In addition to identifying critical points based on the various datasources, the navigation application of some embodiments identifiescritical points using calculations based on road vector data, historicaccident data, etc. For example, in some embodiments, the navigationapplication analyzes historic accident data to identify locations alongthe route with a high accident rate.

In addition to performing calculations to identify critical points, thenavigation application performs calculations to identify additionalinformation, or condition factors, based on the collected informationand the identified critical points in order to provide the dynamicnavigation warnings. In some embodiments, the navigation applicationcalculates condition factors such as a safe traveling speed, an amountof time to reach the safe traveling speed for a critical point, astopping distance for the vehicle, etc. For example, in someembodiments, a safe traveling speed for a particular curve is calculatedfor the vehicle based on the tire and brake conditions, as well asweather conditions. The time to reach the safe traveling speed may bebased on the calculated safe traveling speed as well as the distance tothe critical point. These calculated values are then used to providedynamic navigation warnings by, for example, modifying the timing or theinstruction for a navigation warning based on the safe traveling speed.

In some embodiments, the calculations are based on a set of lookuptables that provides weightings or adjustment values for differentconditions. For example, in some embodiments, when the navigationapplication determines that it is raining, the navigation applicationaccesses a weather lookup table to identify an adjustment value forsnowy weather. The navigation application uses the adjustment value, ora set of adjustment values, to determine the different condition factorssuch as a safe traveling speed or a stopping distance. For example, ifthe adjustment value for snowy weather is 0.8, and the normal safetraveling speed for a particular curve is 45 mph, the navigationapplication may determine that the safe speed for the curve during snowyweather is 36 mph. In some embodiments, the speeds are rounded to thenearest multiple of 5 (i.e., 36 mph would be rounded to 35 mph).

The navigation application of some embodiments uses more involvedcalculations to determine the different condition factors. In someembodiments, rather than simply performing a lookup for the currentweather conditions, the navigation application collects additionalweather information, such as previous weather conditions to calculatethe condition factors. For example, the navigation application of someembodiments accounts for how long it has been raining, or when itdetects freezing temperatures, determines whether it has rained recentlyto determine a likelihood for black ice or other dangerous roadconditions.

III. Providing Dynamic Warnings

Based on the collected data and calculated information, the navigationapplication of some embodiments generates dynamic navigation warnings.FIG. 4 conceptually illustrates a process for generating dynamicnavigation warnings. FIG. 4 will be described with reference to FIGS.5-7. The process 400 of some embodiments is performed by the warninggeneration module 320 as described above with reference to FIG. 3.

The process 400 receives (at 405) the information collected andcalculated as described above in Sections I and II. The process 400determines (at 410) whether a navigation warning should be provided tothe user. In some embodiments, determining whether to provide anavigation warning is based on the collected and calculated information.For example, when the vehicle is already traveling at the safe travelingspeed for a particular curve, the navigation application may determinethat no navigation warning is necessary. When the process 400 determines(at 410) not to provide a navigation warning, the process 400 returns tostep 405.

FIG. 5 illustrates different scenarios in which a navigation applicationdetermines whether to provide a navigation warning. The navigationapplication performs the determination based on various types of datathat are collected. In the first scenario 501, the vehicle 510 istraveling along the road 505 at 55 mph. The weather is sunny and theroads are dry, so the navigation application determines that 55 mph is asafe speed for the approaching curve 520. In the first scenario 501, thenavigation application determines that a navigation warning is notnecessary and does not provide a navigation warning for the user.

The second scenario 502 illustrates an example in which the vehicle isspeeding along at 75 mph. As the vehicle is traveling at a speed that isbeyond a safe threshold for the approaching curve 520, the navigationapplication determines that a navigation warning is desired and presentsa navigation warning 525. The navigation warning 525 advises the user toreduce their speed to 55 mph.

The third scenario 503 illustrates an example in which the roadconditions are good, but because it is a cloudy night, visibility isaffected. In some embodiments, the navigation application would notnormally provide a navigation warning because the user is alreadytraveling at a safe traveling speed with enough time to slow down afterseeing the sign 515. However, in this scenario, the navigationapplication determines that a navigation warning should be providedbecause the signage 515 regarding the upcoming curve 520 may not beclearly visible due to the dark. The navigation application provides anavigation warning 525, warning the user to reduce their speed to 55mph.

The fourth scenario 504 illustrates an example in which the navigationapplication determines whether to provide a navigation warning based onthe weather. In some embodiments, the navigation application determinesto provide a navigation warning when the instruction for the warning isdifferent than warnings provided by street signs or with the route data.In the example of the fourth scenario 504, the weather is rainy andresults in poor road conditions. Based on the weather, as well as thebraking and tire condition of the vehicle, the navigation applicationdetermines that a safe speed for the upcoming curve 520 is lower thanthe presented sign 515 and provides a navigation warning 525 with aninstruction advising the user to slow down to 45 mph. In addition todetermining that a navigation warning should be provided, in the exampleof stage 504, the navigation instruction for the navigation warning wasalso modified based on the road conditions. Examples of modifying thenavigation instructions for a navigation warning are described belowwith reference to FIG. 6.

Referring back to FIG. 4, when the process determines (at 410) toprovide a navigation warning, the process 400 determines whether tomodify (at 415) the navigation warning. The navigation warning may bemodified in different ways based on the various collected information.

FIG. 6 illustrates different scenarios in which a navigation applicationmodifies different aspects of a navigation warning. In the firstscenario 601, the vehicle 610 is traveling along the road 605. Astandard navigation warning 625 is provided at a default time ordistance prior to the critical point, i.e., curve 620. In the firstscenario 601, the navigation instruction of the navigation warning 625advises the driver to slow down to 55 mph. In some embodiments, this isa default instruction that is received as a part of the route.

In the second scenario 602, unlike the first scenario 601, the weatheris poor, indicating possibly slick road conditions. The navigationapplication calculates a safe traveling speed based on the environmentaldata and determines that the default instruction to drive at 55 mph isno longer appropriate. The navigation application modifies thenavigation instruction of the navigation warning 625, advising the userto slow down to 45 mph, rather than 55 mph. The navigation applicationof some embodiments modifies the instruction of the navigation warningbased on the collected and calculated information to allow a user totravel at a safe speed through the critical points along the route.

As another example of modifying the instruction of a navigation warning,the navigation application of some embodiments modifies the instructionof a navigation warning to advise the user to travel in a particularlane along the route. For example, when a pothole is identified alongthe route (e.g., through a road hazards database), the navigationapplication of some embodiments modifies the instruction of a navigationwarning to advise a user to travel in a particular lane along the road.In some embodiments, rather than modifying an existing instruction, thenavigation application provides a new instruction to direct the user tomove to a specified lane.

In the third scenario 603, like the second scenario 602, the weather ispoor and the navigation application provides navigation instruction 625.However, in the third scenario 603, the vehicle is traveling at night.The navigation application determines that the weather and the time ofday have affected visibility, requiring increased attention to the road.In some embodiments, when the navigation application determines thatincreased attention is required on the road, the navigation applicationnot only modifies the instruction of the navigation warning (e.g.,reducing the recommended speed from 55 mph to 45 mph), but also modifiesthe way that the warning is provided. For example, in some embodiments,the navigation application provides an audio warning rather than (or inaddition to) a warning on the screen of the device, even when thenavigation application is not set to provide audio navigationinstructions. By modifying the way that the warning is provided, thenavigation application is able to emphasize the importance of anupcoming critical point and to provide safer instructions because theuser does not have to watch the display screen of the device.

Referring back to FIG. 4, the process 400 then determines (at 425)whether to modify the timing for the navigation warning. As withdetermining whether to modify the warning instruction at step 415, theprocess 400 takes the collected and calculated information anddetermines whether to change the timing for a navigation warning. Insome embodiments, the timing for the navigation warning is not modifiedand is presented at a set time or distance before reaching a criticalpoint. When the process 400 determines (at 425) not to modify the timingfor the warning instruction, the process continues to step 435 andprovides the navigation warning.

When the process 400 determines (at 425) to modify the timing for thenavigation warning, the process modifies (at 430) the timing for thenavigation warning. The timing for the navigation warning of someembodiments is modified based on route, vehicle or environmentalconditions in order to give the driver enough time to safely decelerateto the safe traveling speed. In some embodiments, the process 400analyzes the safe traveling speed for a critical point and the time ordistance necessary to reach the safe traveling speed in order tocalculate a time or distance prior to the critical point at which toprovide the navigation warning. As another example, in some embodiments,each navigation warning has a default time or distance before thecritical point at which the warning is presented. The process 400 thenuses adjustment values to weight the different environmental or vehicleconditions to shorten or lengthen the time or distance before thecritical point at which the warning is presented.

FIG. 7 illustrates an example of modifying the timing for a navigationwarning. The first scenario 701 illustrates an example in which, on asunny day, a first warning 725 is provided for the user. The firstwarning 725 includes an instruction to reduce the speed to 55 mph. Thefirst warning 725 may be a default warning that is set to display at aparticular time or distance before a critical point and is unmodifiedbecause the weather and road conditions are good.

The second scenario 702 illustrates an example in which, like theexample of scenario 502 of FIG. 5, the instruction for navigationwarning 725 is modified to advise the user to reduce speed to 45 mph.However, in this scenario, in addition to modifying the instruction, thenavigation warning is provided to the user at an earlier point in timethan the warning 725 that is provided in the first scenario 701. In thisexample, the navigation application determines that the roads may beslick due to the rain, and in addition to identifying a lower safetravel speed, the navigation application also determines that it willtake longer to decelerate to the safe traveling speed. The navigationapplication of some embodiments uses an adjustment value based on thevarious condition factors to modify the navigation warning to bepresented to the user at an earlier time or at a greater distance beforethe critical point. While in this example, both the instruction and thetiming of the navigation warning are modified, in some embodiments, onlyone or neither of the modifications may be performed on the navigationwarning.

The process 400 provides (at 435) the navigation warnings. Thenavigation warnings of some embodiments are provided on a display screenof a device, through speakers of either the audio device or the vehicle,or a combination of the two, or through any other method of output.

IV. Electronic Device and System

Many of the above-described features and applications are implemented assoftware processes that are specified as a set of instructions recordedon a computer or machine readable storage medium (also referred to ascomputer or machine readable medium). When these instructions areexecuted by one or more computational or processing unit(s) (e.g., oneor more processors, cores of processors, or other processing units),they cause the processing unit(s) to perform the actions indicated inthe instructions. Examples of computer readable media include, but arenot limited to, CD-ROMs, flash drives, random access memory (RAM) chips,hard drives, erasable programmable read-only memories (EPROMs),electrically erasable programmable read-only memories (EEPROMs), etc.The computer readable media does not include carrier waves andelectronic signals passing wirelessly or over wired connections.

In this specification, the term “software” is meant to include firmwareresiding in read-only memory or applications stored in magnetic storagewhich can be read into memory for processing by a processor. Also, insome embodiments, multiple software inventions can be implemented assub-parts of a larger program while remaining distinct softwareinventions. In some embodiments, multiple software inventions can alsobe implemented as separate programs. Finally, any combination ofseparate programs that together implement a software invention describedhere is within the scope of the invention. In some embodiments, thesoftware programs, when installed to operate on one or more electronicsystems, define one or more specific machine implementations thatexecute and perform the operations of the software programs.

The mapping and navigation applications of some embodiments operate onmobile devices, such as smart phones (e.g., iPhones®) and tablets (e.g.,iPads®). FIG. 8 is an example of an architecture 800 of such a mobilecomputing device. Examples of mobile computing devices includesmartphones, tablets, laptops, etc. As shown, the mobile computingdevice 800 includes one or more processing units 805, a memory interface810 and a peripherals interface 815.

The peripherals interface 815 is coupled to various sensors andsubsystems, including a camera subsystem 820, a wireless communicationsubsystem(s) 825, an audio subsystem 830, an I/O subsystem 835, etc. Theperipherals interface 815 enables communication between the processingunits 805 and various peripherals. For example, an orientation sensor845 (e.g., a gyroscope) and an acceleration sensor 850 (e.g., anaccelerometer) is coupled to the peripherals interface 815 to facilitateorientation and acceleration functions.

The camera subsystem 820 is coupled to one or more optical sensors 840(e.g., a charged coupled device (CCD) optical sensor, a complementarymetal-oxide-semiconductor (CMOS) optical sensor, etc.). The camerasubsystem 820 coupled with the optical sensors 840 facilitates camerafunctions, such as image and/or video data capturing. The wirelesscommunication subsystem 825 serves to facilitate communicationfunctions. In some embodiments, the wireless communication subsystem 825includes radio frequency receivers and transmitters, and opticalreceivers and transmitters (not shown in FIG. 8). These receivers andtransmitters of some embodiments are implemented to operate over one ormore communication networks such as a GSM network, a Wi-Fi network, aBluetooth network, etc. The audio subsystem 830 is coupled to a speakerto output audio (e.g., to output voice navigation instructions).Additionally, the audio subsystem 830 is coupled to a microphone tofacilitate voice-enabled functions, such as voice recognition (e.g., forsearching), digital recording, etc.

Conjunctively, or alternatively, some embodiments also include a wiredcommunication subsystem to facilitate communication functions with avehicle's electronic system. In some embodiments, the wiredcommunication system includes a USB connector for connecting the mobiledevice to a vehicle electronic system. The interface of some embodimentsfor communicating with a vehicle electronic system is described infurther detail in U.S. Patent Publications 2009/0284476, 2010/0293462,2011/0145863, 2011/0246891, and 2011/085003, which are incorporatedherein by reference.

The I/O subsystem 835 involves the transfer between input/outputperipheral devices, such as a display, a touch screen, etc., and thedata bus of the processing units 805 through the peripherals interface815. The I/O subsystem 835 includes a touch-screen controller 855 andother input controllers 860 to facilitate the transfer betweeninput/output peripheral devices and the data bus of the processing units805. As shown, the touch-screen controller 855 is coupled to a touchscreen 865. The touch-screen controller 855 detects contact and movementon the touch screen 865 using any of multiple touch sensitivitytechnologies. The other input controllers 860 are coupled to otherinput/control devices, such as one or more buttons. Some embodimentsinclude a near-touch sensitive screen and a corresponding controllerthat can detect near-touch interactions instead of or in addition totouch interactions.

The memory interface 810 is coupled to memory 870. In some embodiments,the memory 870 includes volatile memory (e.g., high-speed random accessmemory), non-volatile memory (e.g., flash memory), a combination ofvolatile and non-volatile memory, and/or any other type of memory. Asillustrated in FIG. 8, the memory 870 stores an operating system (OS)872. The OS 872 includes instructions for handling basic system servicesand for performing hardware dependent tasks.

The memory 870 also includes communication instructions 874 tofacilitate communicating with one or more additional devices; graphicaluser interface instructions 876 to facilitate graphic user interfaceprocessing; image processing instructions 878 to facilitateimage-related processing and functions; input processing instructions880 to facilitate input-related (e.g., touch input) processes andfunctions; audio processing instructions 882 to facilitate audio-relatedprocesses and functions; and camera instructions 884 to facilitatecamera-related processes and functions. The instructions described aboveare merely exemplary and the memory 870 includes additional and/or otherinstructions in some embodiments. For instance, the memory for asmartphone may include phone instructions to facilitate phone-relatedprocesses and functions. Additionally, the memory may includeinstructions for a mapping and navigation application as well as otherapplications. The above-identified instructions need not be implementedas separate software programs or modules. Various functions of themobile computing device can be implemented in hardware and/or insoftware, including in one or more signal processing and/or applicationspecific integrated circuits.

While the components illustrated in FIG. 8 are shown as separatecomponents, one of ordinary skill in the art will recognize that two ormore components may be integrated into one or more integrated circuits.In addition, two or more components may be coupled together by one ormore communication buses or signal lines. Also, while many of thefunctions have been described as being performed by one component, oneof ordinary skill in the art will realize that the functions describedwith respect to FIG. 8 may be split into two or more integratedcircuits.

Some embodiments include electronic components, such as microprocessors,storage and memory that store computer program instructions in amachine-readable or computer-readable medium (alternatively referred toas computer-readable storage media, machine-readable media, ormachine-readable storage media). Some examples of such machine-readablemedia include RAM, ROM, read-only compact discs (CD-ROM), recordablecompact discs (CD-R), rewritable compact discs (CD-RW), read-onlydigital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a varietyof recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.),flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.),magnetic and/or solid state hard drives, read-only and recordableBlu-Ray® discs, ultra density optical discs, any other optical ormagnetic media, and floppy disks. The machine-readable media may store aprogram that is executable by at least one processing unit and includessets of instructions for performing various operations. Examples ofprograms or code include machine code, such as is produced by acompiler, and files including higher-level code that are executed by acomputer, an electronic component, or a microprocessor using aninterpreter.

While the above discussion primarily refers to microprocessor ormulti-core processors that execute software, some embodiments areperformed by one or more integrated circuits, such as applicationspecific integrated circuits (ASICs), customized ASICs or fieldprogrammable gate arrays (FPGAs). In some embodiments, such integratedcircuits execute instructions that are stored on the circuit itself. Inaddition, some embodiments execute software stored in programmable logicdevices (PLDs), ROM, or RAM devices.

As used in this specification and any claims of this application, theterms “computer”, “server”, “processor”, and “memory” all refer toelectronic or other technological devices. These terms exclude people orgroups of people. For the purposes of the specification, the termsdisplay or displaying means displaying on an electronic device. As usedin this specification and any claims of this application, the terms“computer readable medium,” “computer readable media,” and “machinereadable medium” are entirely restricted to tangible, physical objectsthat store information in a form that is readable by a computer. Theseterms exclude any wireless signals, wired download signals, and anyother ephemeral signals.

As mentioned above, various embodiments may operate within a map serviceoperating environment. FIG. 9 illustrates a map service operatingenvironment, according to some embodiments. A map service 930 (alsoreferred to as mapping service) may provide map services for one or moreclient devices 902 a-902 c in communication with the map service 930through various communication methods and protocols. A map service 930in some embodiments provides map information and other map-related data,such as two-dimensional map image data (e.g., aerial view of roadsutilizing satellite imagery), three-dimensional map image data (e.g.,traversable map with three-dimensional features, such as buildings),route and direction calculation (e.g., ferry route calculations ordirections between two points for a pedestrian), real-time navigationdata (e.g., turn-by-turn visual navigation data in two or threedimensions), location data (e.g., where is the client device currentlylocated), and other geographic data (e.g., wireless network coverage,weather, traffic information, or nearby points-of-interest). In variousembodiments, the map service data may include localized labels fordifferent countries or regions; localized labels may be utilized topresent map labels (e.g., street names, city names, points of interest)in different languages on client devices. Client devices 902 a-902 c mayutilize these map services by obtaining map service data. Client devices902 a-902 c may implement various techniques to process map servicedata. Client devices 902 a-902 c may then provide map services tovarious entities, including, but not limited to, users, internalsoftware or hardware modules, and/or other systems or devices externalto the client devices 902 a-902 c.

In some embodiments, a map service is implemented by one or more nodesin a distributed computing system. Each node may be assigned one or moreservices or components of a map service. Some nodes may be assigned thesame map service or component of a map service. A load balancing node insome embodiments distributes access or requests to other nodes within amap service. In some embodiments a map service is implemented as asingle system, such as a single server. Different modules or hardwaredevices within a server may implement one or more of the variousservices provided by a map service.

A map service in some embodiments provides map services by generatingmap service data in various formats. In some embodiments, one format ofmap service data is map image data. Map image data provides image datato a client device so that the client device may process the image data(e.g., rendering and/or displaying the image data as a two-dimensionalor three-dimensional map). Map image data, whether in two or threedimensions, may specify one or more map tiles. A map tile may be aportion of a larger map image. Assembling together the map tiles of amap produces the original map. Tiles may be generated from map imagedata, routing or navigation data, or any other map service data. In someembodiments map tiles are raster-based map tiles, with tile sizesranging from any size both larger and smaller than a commonly-used 256pixel by 256 pixel tile. Raster-based map tiles may be encoded in anynumber of standard digital image representations including, but notlimited to, Bitmap (.bmp), Graphics Interchange Format (.gif), JointPhotographic Experts Group (.jpg, .jpeg, etc.), Portable NetworksGraphic (.png), or Tagged Image File Format (.tiff). In someembodiments, map tiles are vector-based map tiles, encoded using vectorgraphics, including, but not limited to, Scalable Vector Graphics (.svg)or a Drawing File (.drw). Some embodiments also include tiles with acombination of vector and raster data. Metadata or other informationpertaining to the map tile may also be included within or along with amap tile, providing further map service data to a client device. Invarious embodiments, a map tile is encoded for transport utilizingvarious standards and/or protocols, some of which are described inexamples below.

In various embodiments, map tiles may be constructed from image data ofdifferent resolutions depending on zoom level. For instance, for lowzoom level (e.g., world or globe view), the resolution of map or imagedata need not be as high relative to the resolution at a high zoom level(e.g., city or street level). For example, when in a globe view, theremay be no need to render street level artifacts as such objects would beso small as to be negligible in many cases.

A map service in some embodiments performs various techniques to analyzea map tile before encoding the tile for transport. This analysis mayoptimize map service performance for both client devices and a mapservice. In some embodiments map tiles are analyzed for complexity,according to vector-based graphic techniques, and constructed utilizingcomplex and non-complex layers. Map tiles may also be analyzed forcommon image data or patterns that may be rendered as image textures andconstructed by relying on image masks. In some embodiments, raster-basedimage data in a map tile contains certain mask values, which areassociated with one or more textures. Some embodiments also analyze maptiles for specified features that may be associated with certain mapstyles that contain style identifiers.

Other map services generate map service data relying upon various dataformats separate from a map tile in some embodiments. For instance, mapservices that provide location data may utilize data formats conformingto location service protocols, such as, but not limited to, RadioResource Location services Protocol (RRLP), TIA 801 for Code DivisionMultiple Access (CDMA), Radio Resource Control (RRC) position protocol,or LTE Positioning Protocol (LPP). Embodiments may also receive orrequest data from client devices identifying device capabilities orattributes (e.g., hardware specifications or operating system version)or communication capabilities (e.g., device communication bandwidth asdetermined by wireless signal strength or wire or wireless networktype).

A map service may obtain map service data from internal or externalsources. For example, satellite imagery used in map image data may beobtained from external services, or internal systems, storage devices,or nodes. Other examples may include, but are not limited to, GPSassistance servers, wireless network coverage databases, business orpersonal directories, weather data, government information (e.g.,construction updates or road name changes), or traffic reports. Someembodiments of a map service may update map service data (e.g., wirelessnetwork coverage) for analyzing future requests from client devices.

Various embodiments of a map service may respond to client devicerequests for map services. These requests may be a request for aspecific map or portion of a map. Some embodiments format requests for amap as requests for certain map tiles. In some embodiments, requestsalso supply the map service with starting locations (or currentlocations) and destination locations for a route calculation. A clientdevice may also request map service rendering information, such as maptextures or style sheets. In at least some embodiments, requests arealso one of a series of requests implementing turn-by-turn navigation.Requests for other geographic data may include, but are not limited to,current location, wireless network coverage, weather, trafficinformation, or nearby points-of-interest.

A map service, in some embodiments, analyzes client device requests tooptimize a device or map service operation. For instance, a map servicemay recognize that the location of a client device is in an area of poorcommunications (e.g., weak wireless signal) and send more map servicedata to supply a client device in the event of loss in communication orsend instructions to utilize different client hardware (e.g.,orientation sensors) or software (e.g., utilize wireless locationservices or Wi-Fi positioning instead of GPS-based services). In anotherexample, a map service may analyze a client device request forvector-based map image data and determine that raster-based map databetter optimizes the map image data according to the image's complexity.Embodiments of other map services may perform similar analysis on clientdevice requests and as such the above examples are not intended to belimiting.

Various embodiments of client devices (e.g., client devices 902 a-902 c)are implemented on different portable-multifunction device types. Clientdevices 902 a-902 c utilize map service 930 through variouscommunication methods and protocols. In some embodiments, client devices902 a-902 c obtain map service data from map service 930. Client devices902 a-902 c request or receive map service data. Client devices 902a-902 c then process map service data (e.g., render and/or display thedata) and may send the data to another software or hardware module onthe device or to an external device or system.

A client device, according to some embodiments, implements techniques torender and/or display maps. These maps may be requested or received invarious formats, such as map tiles described above. A client device mayrender a map in two-dimensional or three-dimensional views. Someembodiments of a client device display a rendered map and allow a user,system, or device providing input to manipulate a virtual camera in themap, changing the map display according to the virtual camera'sposition, orientation, and field-of-view. Various forms and inputdevices are implemented to manipulate a virtual camera. In someembodiments, touch input, through certain single or combination gestures(e.g., touch-and-hold or a swipe) manipulate the virtual camera. Otherembodiments allow manipulation of the device's physical location tomanipulate a virtual camera. For instance, a client device may be tiltedup from its current position to manipulate the virtual camera to rotateup. In another example, a client device may be tilted forward from itscurrent position to move the virtual camera forward. Other input devicesto the client device may be implemented including, but not limited to,auditory input (e.g., spoken words), a physical keyboard, mouse, and/ora joystick.

Some embodiments provide various visual feedback to virtual cameramanipulations, such as displaying an animation of possible virtualcamera manipulations when transitioning from two-dimensional map viewsto three-dimensional map views. Some embodiments also allow input toselect a map feature or object (e.g., a building) and highlight theobject, producing a blur effect that maintains the virtual camera'sperception of three-dimensional space.

In some embodiments, a client device implements a navigation system(e.g., turn-by-turn navigation). A navigation system provides directionsor route information, which may be displayed to a user. Some embodimentsof a client device request directions or a route calculation from a mapservice. A client device may receive map image data and route data froma map service. In some embodiments, a client device implements aturn-by-turn navigation system, which provides real-time route anddirection information based upon location information and routeinformation received from a map service and/or other location system,such as Global Positioning Satellite (GPS). A client device may displaymap image data that reflects the current location of the client deviceand update the map image data in real-time. A navigation system mayprovide auditory or visual directions to follow a certain route.

A virtual camera is implemented to manipulate navigation map dataaccording to some embodiments. Some embodiments of client devices allowthe device to adjust the virtual camera display orientation to biastoward the route destination. Some embodiments also allow virtual camerato navigation turns simulating the inertial motion of the virtualcamera.

Client devices implement various techniques to utilize map service datafrom map service. Some embodiments implement some techniques to optimizerendering of two-dimensional and three-dimensional map image data. Insome embodiments, a client device locally stores rendering information.For instance, a client stores a style sheet which provides renderingdirections for image data containing style identifiers. In anotherexample, common image textures may be stored to decrease the amount ofmap image data transferred from a map service. Client devices indifferent embodiments implement various modeling techniques to rendertwo-dimensional and three-dimensional map image data, examples of whichinclude, but are not limited to: generating three-dimensional buildingsout of two-dimensional building footprint data; modeling two-dimensionaland three-dimensional map objects to determine the client devicecommunication environment; generating models to determine whether maplabels are seen from a certain virtual camera position; and generatingmodels to smooth transitions between map image data. Some embodiments ofclient devices also order or prioritize map service data in certaintechniques. For instance, a client device detects the motion or velocityof a virtual camera, which if exceeding certain threshold values,lower-detail image data is loaded and rendered of certain areas. Otherexamples include: rendering vector-based curves as a series of points,preloading map image data for areas of poor communication with a mapservice, adapting textures based on display zoom level, or rendering mapimage data according to complexity.

In some embodiments, client devices communicate utilizing various dataformats separate from a map tile. For instance, some client devicesimplement Assisted Global Positioning Satellites (A-GPS) and communicatewith location services that utilize data formats conforming to locationservice protocols, such as, but not limited to, Radio Resource Locationservices Protocol (RRLP), TIA 801 for Code Division Multiple Access(CDMA), Radio Resource Control (RRC) position protocol, or LTEPositioning Protocol (LPP). Client devices may also receive GPS signalsdirectly. Embodiments may also send data, with or without solicitationfrom a map service, identifying the client device's capabilities orattributes (e.g., hardware specifications or operating system version)or communication capabilities (e.g., device communication bandwidth asdetermined by wireless signal strength or wire or wireless networktype).

FIG. 9 illustrates one possible embodiment of an operating environment900 for a map service 930 and client devices 902 a-902 c. In someembodiments, devices 902 a, 902 b, and 902 c communicate over one ormore wire or wireless networks 910. For example, wireless network 910,such as a cellular network, can communicate with a wide area network(WAN) 920, such as the Internet, by use of gateway 914. A gateway 914 insome embodiments provides a packet oriented mobile data service, such asGeneral Packet Radio Service (GPRS), or other mobile data serviceallowing wireless networks to transmit data to other networks, such aswide area network 920. Likewise, access device 912 (e.g., IEEE 802.11gwireless access device) provides communication access to WAN 920.Devices 902 a and 902 b can be any portable electronic or computingdevice capable of communicating with a map service. Device 902 c can beany non-portable electronic or computing device capable of communicatingwith a map service.

In some embodiments, both voice and data communications are establishedover wireless network 910 and access device 912. For instance, device902 a can place and receive phone calls (e.g., using voice over InternetProtocol (VoIP) protocols), send and receive e-mail messages (e.g.,using Simple Mail Transfer Protocol (SMTP) or Post Office Protocol 3(POP3)), and retrieve electronic documents and/or streams, such as webpages, photographs, and videos, over wireless network 910, gateway 914,and WAN 920 (e.g., using Transmission Control Protocol/Internet Protocol(TCP/IP) or User Datagram Protocol (UDP)). Likewise, in someimplementations, devices 902 b and 902 c can place and receive phonecalls, send and receive e-mail messages, and retrieve electronicdocuments over access device 912 and WAN 920. In various embodiments,any of the illustrated client device may communicate with map service930 and/or other service(s) 950 using a persistent connectionestablished in accordance with one or more security protocols, such asthe Secure Sockets Layer (SSL) protocol or the Transport Layer Security(TLS) protocol.

Devices 902 a and 902 b can also establish communications by othermeans. For example, wireless device 902 a can communicate with otherwireless devices (e.g., other devices 902 b, cell phones, etc.) over thewireless network 910. Likewise devices 902 a and 902 b can establishpeer-to-peer communications 940 (e.g., a personal area network) by useof one or more communication subsystems, such as Bluetooth®communication from Bluetooth Special Interest Group, Inc. of Kirkland,Wash. Device 902 c can also establish peer to peer communications withdevices 902 a or 902 b (not shown). Other communication protocols andtopologies can also be implemented. Devices 902 a and 902 b may alsoreceive Global Positioning Satellite (GPS) signals from GPS satellites960.

Devices 902 a, 902 b, and 902 c can communicate with map service 930over the one or more wire and/or wireless networks, 910 or 912. Forinstance, map service 930 can provide a map service data to renderingdevices 902 a, 902 b, and 902 c. Map service 930 may also communicatewith other services 950 to obtain data to implement map services. Mapservice 930 and other services 950 may also receive GPS signals from GPSsatellites 960.

In various embodiments, map service 930 and/or other service(s) 950 areconfigured to process search requests from any of client devices. Searchrequests may include but are not limited to queries for business,address, residential locations, points of interest, or some combinationthereof. Map service 930 and/or other service(s) 950 may be configuredto return results related to a variety of parameters including but notlimited to a location entered into an address bar or other text entryfield (including abbreviations and/or other shorthand notation), acurrent map view (e.g., user may be viewing one location on themultifunction device while residing in another location), currentlocation of the user (e.g., in cases where the current map view did notinclude search results), and the current route (if any). In variousembodiments, these parameters may affect the composition of the searchresults (and/or the ordering of the search results) based on differentpriority weightings. In various embodiments, the search results that arereturned may be a subset of results selected based on specific criteriainclude but not limited to a quantity of times the search result (e.g.,a particular point of interest) has been requested, a measure of qualityassociated with the search result (e.g., highest user or editorialreview rating), and/or the volume of reviews for the search results(e.g., the number of times the search result has been review or rated).

In various embodiments, map service 930 and/or other service(s) 950 areconfigured to provide auto-complete search results that are displayed onthe client device, such as within the mapping application. For instance,auto-complete search results may populate a portion of the screen as theuser enters one or more search keywords on the multifunction device. Insome cases, this feature may save the user time as the desired searchresult may be displayed before the user enters the full search query. Invarious embodiments, the auto complete search results may be searchresults found by the client on the client device (e.g., bookmarks orcontacts), search results found elsewhere (e.g., from the Internet) bymap service 930 and/or other service(s) 950, and/or some combinationthereof. As is the case with commands, any of the search queries may beentered by the user via voice or through typing. The multifunctiondevice may be configured to display search results graphically withinany of the map display described herein. For instance, a pin or othergraphical indicator may specify locations of search results as points ofinterest. In various embodiments, responsive to a user selection of oneof these points of interest (e.g., a touch selection, such as a tap),the multifunction device is configured to display additional informationabout the selected point of interest including but not limited toratings, reviews or review snippets, hours of operation, store status(e.g., open for business, permanently closed, etc.), and/or images of astorefront for the point of interest. In various embodiments, any ofthis information may be displayed on a graphical information card thatis displayed in response to the user's selection of the point ofinterest.

In various embodiments, map service 930 and/or other service(s) 950provide one or more feedback mechanisms to receive feedback from clientdevices 902 a-902 c. For instance, client devices may provide feedbackon search results to map service 930 and/or other service(s) 950 (e.g.,feedback specifying ratings, reviews, temporary or permanent businessclosures, errors etc.); this feedback may be used to update informationabout points of interest in order to provide more accurate or moreup-to-date search results in the future. In some embodiments, mapservice 930 and/or other service(s) 950 may provide testing informationto the client device (e.g., an A/B test) to determine which searchresults are best. For instance, at random intervals, the client devicemay receive and present two search results to a user and allow the userto indicate the best result. The client device may report the testresults to map service 930 and/or other service(s) 950 to improve futuresearch results based on the chosen testing technique, such as an A/Btest technique in which a baseline control sample is compared to avariety of single-variable test samples in order to improve results.

While the invention has been described with reference to numerousspecific details, one of ordinary skill in the art will recognize thatthe invention can be embodied in other specific forms without departingfrom the spirit of the invention. For instance, many of the figuresillustrate various touch gestures (e.g., taps, double taps, swipegestures, press and hold gestures, etc.). However, many of theillustrated operations could be performed via different touch gestures(e.g., a swipe instead of a tap, etc.) or by non-touch input (e.g.,using a cursor controller, a keyboard, a touchpad/trackpad, a near-touchsensitive screen, etc.).

Also, numerous examples were provided above for using the predicteddestinations, predicted routes, or data regarding the predicteddestinations or routes to drive the operations of one or moreapplications. However, one of ordinary skill will realize that suchpredictions or associated data can be used to inform many otherapplications not described above. For example, a weather application ora notification manager can use the predicted destination or routeinformation to provide weather at a predicted destination or along apredicted route. Many other examples of informing the operation of manyother applications with predicted route, destination or related dataexist. Thus, one of ordinary skill in the art would understand that theinvention is not to be limited by the foregoing illustrative details,but rather is to be defined by the appended claims.

What is claimed is:
 1. A system comprising: a display device; one ormore processing units; and a non-transitory machine readable mediumstoring a program which when executed by at least one processing unit ofa mobile device generates a plurality of navigation warnings for avehicle traveling a route, the program comprising instructions for:determining that the vehicle is approaching a critical point along theroute; selecting, based on the determination, a navigation warning topresent; receiving vehicle data and environmental data associated withthe vehicle, the environmental data including visibility of streetsignage; when the vehicle data and environmental data indicate a firstcondition, presenting the navigation warning using a first outputmethod; and when the vehicle data and environmental data indicate asecond condition, presenting the navigation warning using a secondoutput method.
 2. The system of claim 1, wherein the environmental datadescribes conditions external to the vehicle and the vehicle datadescribes conditions of the vehicle.
 3. The system of claim 2, whereinthe instructions for receiving the environmental data comprisesinstructions for receiving weather data.
 4. The system of claim 3,wherein the instructions for receiving the weather data comprisesinstructions for accessing external sensors of the vehicle.
 5. Thesystem of claim 3, wherein the instructions for receiving the weatherdata comprises instructions for accessing a weather service over anetwork.
 6. The system of claim 2, wherein the navigation warningcomprises an instruction to travel in a particular lane along a road. 7.The system of claim 2, wherein the instructions for receiving theenvironmental data comprises instructions for receiving ambient lightdata.
 8. The system of claim 2, wherein the instructions for receivingthe vehicle data comprises instructions for determining a current speedof travel for the vehicle.
 9. The system of claim 1, wherein theinstructions for presenting the navigation warning comprisesinstructions for providing a reduced speed at which to travel.
 10. Thesystem of claim 1, wherein the data is associated with current roadconditions for an upcoming portion of the route, wherein the programfurther comprises instructions for: identifying a designated speed foran upcoming portion of a route; and calculating a safe speed at which totravel along the upcoming portion of the route that is different fromthe designated speed based on the received data, and presenting thecalculated safe speed.
 11. The system of claim 1, wherein the criticalpoint includes one or more of a hazardous curve, a road hazard, and aconstruction incident along the route.
 12. A non-transitory machinereadable medium storing a program which, when executed by at least oneprocessing unit of a mobile device, provides a plurality of navigationwarnings for a vehicle traveling a route, the mobile device comprising adisplay screen, the program comprising instructions for: determiningthat the vehicle is approaching a critical point along the route;selecting, based on the determination, a navigation warning to present;receiving vehicle data and environmental data associated with thevehicle, the environmental data regarding visibility of street signage;when the vehicle data and environmental data indicate a first condition,presenting the navigation warning using a first output method; and whenthe vehicle data and environmental data indicate a second condition,presenting the navigation warning using a second output method.
 13. Thenon-transitory machine readable medium of claim 12, wherein theenvironmental data comprises data regarding a location at which streetsignage becomes visible.
 14. The non-transitory machine readable mediumof claim 13, the program further comprising instructions for:calculating a safe braking distance at which the vehicle can safelyreduce speed for an upcoming turn; and determining that the warning tobe modified when the safe braking distance is greater than a distancebetween the location at which particular street signage for the upcomingturn becomes visible and the upcoming turn.
 15. The non-transitorymachine readable medium of claim 14, the program further comprisinginstructions for determining a timing for providing the instructionbased on the safe braking distance.
 16. The non-transitory machinereadable medium of claim 12, wherein the vehicle data further comprisesvehicle data describing conditions of the vehicle, and environmentaldata describes conditions external to the vehicle.
 17. Thenon-transitory machine readable medium of claim 16, wherein theenvironmental data comprises weather data.
 18. The non-transitorymachine readable medium of claim 16, wherein the instructions forreceiving the vehicle data comprises instructions for determining acurrent speed of travel for the vehicle.
 19. The non-transitory machinereadable medium of claim 12, wherein the plurality of output methodsinclude an audio interface.
 20. The non-transitory machine readablemedium of claim 12, wherein the plurality of output methods include avisual display.
 21. A method implemented by a mobile device forgenerating navigation warnings for a vehicle traveling a route, themethod comprising: determining that the vehicle is approaching acritical point along the route; selecting, based on the determination, anavigation warning to present; receiving vehicle data and environmentaldata associated with the vehicle, the environmental data includingvisibility of street signage; when the vehicle data and environmentaldata indicate a first condition, presenting the navigation warning usinga first output method; and when the vehicle data and environmental dataindicate a second condition, presenting the navigation warning using asecond output method.
 22. The method of claim 21, wherein theenvironmental data describes conditions external to the vehicle and thevehicle data describes conditions of the vehicle.
 23. The method ofclaim 22, wherein receiving the environmental data further comprisesreceiving weather data.
 24. The method of claim 23, wherein theinstructions for receiving the weather data further comprises accessingexternal sensors of the vehicle.
 25. The method of claim 23, wherein theinstructions for receiving the weather data further comprises accessinga weather service over a network.
 26. The method of claim 22, whereinthe navigation warning comprises an instruction to travel in aparticular lane along a road.
 27. The method of claim 22, whereinreceiving the environmental data further comprises instructions forreceiving ambient light data.
 28. The method of claim 22, whereinreceiving the vehicle data comprises determining a current speed oftravel for the vehicle.
 29. The method of claim 21, further comprisingproviding a reduced speed at which to travel.
 30. The method of claim21, wherein the data is associated with current road conditions for anupcoming portion of the route, further comprising: identifying adesignated speed for an upcoming portion of a route; and calculating asafe speed at which to travel along the upcoming portion of the routethat is different from the designated speed based on the received data;and presenting the calculated safe speed.